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             Definition of an IS-IS Link Attribute Sub-TLV

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document defines a sub-TLV called "Link-attributes" carried
   within the TLV 22 and used to flood some link characteristics.

Table of Contents

   1. Introduction ....................................................2
      1.1. Terminology ................................................2
   2. Link-Attributes Sub-TLV Format ..................................2
   3. Interoperability with Routers Not Supporting This Capability ....3
   4. IANA Considerations .............................................3
   5. Security Considerations .........................................3
   6. Acknowledgements ................................................3
   7. References ......................................................4
      7.1. Normative References .......................................4
      7.2. Informative References .....................................4


















Vasseur & Previdi           Standards Track                     [Page 1]

RFC 5029                  IS-IS Link Attribute            September 2007


1.  Introduction

   [IS-IS] specifies the IS-IS protocol (ISO 10589) with extensions to
   support IPv4 in [RFC1195].  A router advertises one or several Link
   State Protocol data units that are composed of variable length tuples
   called TLVs (Type-Length-Value).

   [RFC3784] defines a set of new TLVs whose aims are to add more
   information about links characteristics, increase the range of IS-IS
   metrics, and optimize the encoding of IS-IS prefixes.

   This document defines a new sub-TLV named "Link-attributes" carried
   within the extended IS reachability TLV (type 22) specified in
   [RFC3784].

1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Link-Attributes Sub-TLV Format

   The link-attribute sub-TLV is carried within the TLV 22 and has a
   format identical to the sub-TLV format used by the Traffic
   Engineering Extensions for IS-IS ([RFC3784]): 1 octet of sub-type, 1
   octet of length of the value field of the sub-TLV followed by the
   value field -- in this case, a 16 bit flags field.

   The Link-attribute sub-type is 19 and the link-attribute has a length
   of 2 octets.

   This sub-TLV is OPTIONAL and MUST appear at most once for a single IS
   neighbor.  If a received Link State Packet (LSP) contains more than
   one Link-Attribute Sub-TLV, an implementation SHOULD decide to
   consider only the first encountered instance.

   The following bits are defined:

   Local Protection Available (0x01).  When set, this indicates that the
   link is protected by means of some local protection mechanism (e.g.,
   [RFC4090]).

   Link excluded from local protection path (0x02).  When set, this link
   SHOULD not be included in any computation of a repair path by any
   other router in the routing area.  The triggers for setting up this
   bit are out of the scope of this document.
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3.  Interoperability with Routers Not Supporting This Capability

   A router not supporting the link-attribute sub-TLV will just silently
   ignore this sub-TLV.

4.  IANA Considerations

   IANA has assigned codepoint 19 for the link-attribute sub-TLV defined
   in this document and carried within TLV 22.

   IANA has created a registry for bit values inside the link-attributes
   sub-TLV.  The initial contents of this registry are as follows

     Value   Name                                 Reference
     -----   ----                                 ---------
     0x1     Local Protection Available           [RFC5029]
     0x2     Link Excluded from Local Protection  [RFC5029]

   Further values are to be allocated by the Standards Action process
   defined in [RFC2434], with Early Allocation (defined in [RFC4020])
   permitted.

5.  Security Considerations

   Any new security issues raised by the procedures in this document
   depend upon the opportunity for LSPs to be snooped and modified, the
   ease/difficulty of which has not been altered.  As the LSPs may now
   contain additional information regarding router capabilities, this
   new information would also become available to an attacker.
   Specifications based on this mechanism need to describe the security
   considerations around the disclosure and modification of their
   information.  Note that an integrity mechanism, such as one defined
   in [RFC3567], should be applied if there is high risk resulting from
   the modification of capability information.
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